Claude finished @dario-daza's task in 4m 53s —— View job

PR Review

Endpoint logic is sound and well-tested. A few items worth a second look:

Worth addressing

1. N+1 lookup pattern — undermines the "batch" purpose — WorkflowResource.java:620-637 runs workflowHelper.findSchemesByContentType(id, user) per ID in a sequential stream(). Each call does contentTypeAPI.find(id) + workflowAPI.findSchemesForContentType(...). With the 100-ID cap that's ~200 round trips for the worst case. The whole reason this endpoint exists (per the PR description) is so the frontend doesn't have to call the single-ID endpoint repeatedly — but the server now does exactly that. Consider a single-pass fetch of content types by ID list and one query for their schemes, or document this is a deliberate first cut.

2. Asymmetric error handling on a per-ID failure — At WorkflowResource.java:628-633, only NotFoundInDbException is filtered; any other cause inside DotWorkflowException (notably DotSecurityException, which WorkflowHelper.findSchemesByContentType wraps the same way at WorkflowHelper.java:1341-1345) propagates and fails the entire batch. So "unknown ID → silently skip" but "one ID with insufficient permission → whole request errors." That's surprising for a batch endpoint and not documented in the @Operation description. Either decide explicitly (e.g. skip both with a warn, or fail both) or document the split.

3. Limit check runs on raw tokens before trim/dedup — WorkflowResource.java:607 checks rawTokens.length > MAX_CONTENT_TYPE_IDS before whitespace filtering and .distinct(). The javadoc says "checked before deduplication" so it's intentional, but it means ?contentTypeIds=a,b,a,a,... with 50 unique IDs can still 400 if the raw count exceeds 100. The integration test Find_Schemes_By_Content_Type_List_Exceeds_Max_Size_Expect_BadRequest only covers the obvious case. Worth confirming this is the desired UX — most batch endpoints I've seen check after normalization.

4. Pre-existing truncated UUID (ihoffmann's comment) — dotcms-postman/.../documentation/Workflow Resource.json:156, 6168, 9803, 9812 reference d61a59e1a4 which looks truncated vs the full system workflow ID d61a59e1-a49c-46f2-a929-db2b4bfa88b2 used elsewhere. The bad IDs predate this PR (introduced in 8e880cd) but this PR rewrites the file substantially (+619/-985) and re-emits them. Since you're touching the file, worth fixing — at least the lines you re-introduced.

Minor

5. OpenAPI yaml under-documents the dual format — openapi.yaml:19544-19548 declares name: contentTypeIds, schema: { type: array, items: { type: string } }. OpenAPI 3 defaults to style: form, explode: true, i.e. repeated params (?contentTypeIds=a&contentTypeIds=b). Implementation also accepts comma-separated values, but generated clients won't emit them. Either add style: form, explode: false (drops the repeated form) or note both in the parameter description (you already do in the Java @Parameter, but the explode behavior of style: form is not what the generator will assume here).

6. Logger.warn for skipped IDs — WorkflowResource.java:640-642. If the frontend ever sends stale/typo'd IDs in normal operation this becomes log noise at warn level. Logger.info or debug is probably fine for a user-supplied-bad-input case.

7. Test naming nit — WorkflowResourceResponseCodeIntegrationTest.java:464 Find_Schemes_By_Content_Type_List_Empty_List actually exercises List.of("") (a list with one empty string). The null/empty list cases are covered separately; this test name reads misleadingly.

Nothing else jumped out

• View/Immutables + ResponseEntityContentTypeWorkflowSchemesView follow the @Schema rules.
• Auth path uses InitBuilder with rejectWhenNoUser(true).
• ExceptionUtil.causedBy does walk the cause chain via getClass().equals(...), so the NotFoundInDbException filter works (subclasses would not match, but the factory throws the exact type at ContentTypeFactoryImpl.java:420).
• The LayoutChanges.java change is just an unused import removal — fine.